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(54) System and method of electronic mail-based event scheduling 



(57) An electronic mail-based event scheduling sys- 
tem (10) of the present invention includes a message 
parser (20) accessing an electronic mail message (16) 
received from a sender, extracting scheduling informa- 
tion therefrom, and storing the extracted scheduling in- 
formation in a predetermined format in a globally acces- 
sible record (22). The globally accessible record (22) 
stores extracted scheduling information including event 



scheduler data, event data, resource data, and partici- 
pant data. The system (1 0) also includes a schedule in- 
formation database (60, 62, 68, 72, 84) and an event 
processing function accessing the globally accessible 
record (22) and the schedule information database, per- 
forming a function according to the data therein, and 
preparing and sending an outgoing electronic mail mes- 
sage to the sender and any affected event participant to 
acknowledge and report on the performed function. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001] This invention is related in general to the field 5 
of computer software. More particularly, the invention is 
related to a system and method of electronic mail-based 
event scheduling. 

BACKGROUND OF THE INVENTION w 

[0002] As we enter the new millennium, we are forced 
to process increasing amounts of information. Informa- 
tion come at us in printed form, audio form and electronic 
form from a variety of sources. We not only get informa- is 
tion from traditional sources like newspapers, maga- 
zines, journals, books, radio and television, but also 
from electronic sources like the Internet and the World 
Wide Web. To keep up, we quicken our pace at work 
and at home, and we try to be efficient with our time and 20 
our schedules. However, one thing continues to con- 
found us. That is, the scheduling of meetings at work in 
an efficient manner. 

[0003] Traditionally, a meeting planner would check 
every attendee's schedule to arrive at a date and time 25 
slot that suits everyone. With the prevalent use of elec- 
tronic mail or e-mail, the meeting planner may prefer to 
send out an e-mail message to all attendees to an- 
nounce the tentative meeting date and time. The attend- 
ees are requested to check their respective schedules 30 
and respond with either a M l can attend" or a "I cannot 
make it" and an alternate date and time. The meeting 
planner may go ahead with the original date and time if 
everyone can attend or if the goal of the meeting can 
still be achieved with a small percentage of absentee- 35 
ism. Alternatively, the meeting planner may be forced to 
change the date and time to accommodate one or more 
important attendees who cannot attend at the original 
date and time. This scenario may be repeated until a 
satisfactory date and time can be set. However, the *o 
above illustrates an ideal situation where every attendee 
is prompt about responding to the e-mail or actually 
does respond to the e-mail. Typically, scheduling a 
meeting in a business enterprise that involves more than 
three people is a time consuming and laborious task. 45 
Often meeting dates are postponed repeatedly because 
no consensus can be reached. 
[0004] Existing meeting scheduling software such as 
The meeting planner in MICROSOFT OUTLOOK™ im- 
proves the meeting planning process, but it is still less so 
than ideal. To schedule a meeting or enter an event on 
a calendar using conventional scheduling applications, 
one must have access to the scheduling application via 
a terminal session and enter the schedule information 
via the dedicated user interface of the scheduling appli- 55 
cation. This may be easily done on company premises, 
but is often tricky for remote access. To establish a ter- 
minal session with a scheduling tool such as MS OUT- 
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LOOK™ that is hosted on a company machine, a con- 
nection must be made. For dial-up access, equipment 
(modems and phone line) must be available for each 
dial-up interface. For a large company, several such di- 
al-up equipment is needed. Each user has to connect 
to these modems regardless of their location which 
could be costly if long distance calling charges apply. 
Also, special usage accounts and/or equipment for 
these connections are often required to comply with the 
security requirements of an institution. For telnet access 
(another method of establishing a terminal session), the 
user must have access to a telnet client, know the ma- 
chine name or IP address which hosts the MS OUT- 
LOOK™ application, and have a user account that al- 
lows telnet access. The host machine must also have a 
telnet server which is unpopular for nontechnical busi- 
nesses. 

[0005] Therefore, conventional event scheduling ap- 
plications do not allow easy access from remote loca- 
tions. 

SUMMARY OF THE INVENTION 

[0006] Therefore, there is a need for an event sched- 
uler that allows the users to easily schedule events, 
check his or her own schedule, check the availability of 
event participants, and check the availability of resourc- 
es remotely without having to establish burdensome 
and slow dial-up or telnet connections. 
[0007] In one aspect of the invention, an electronic 
mail-based event scheduling system of the present in- 
vention includes a message parser accessing an elec- 
tronic mail message received from a sender, extracting 
scheduling information therefrom, and storing the ex- 
tracted scheduling information in a predetermined for- 
mat in a globally accessible record. The globally acces- 
sible record stores extracted scheduling information in- 
cluding event scheduler data, event data, resource data, 
and participant data. The system also includes a sched- 
ule information database and an event processing func- 
tion accessing the globally accessible record and the 
schedule information database, performing a function 
according to the data therein, and preparing and send- 
ing an outgoing electronic mail message to the sender 
and any affected event participant to acknowledge and 
report on the performed function. 
[0008] In another aspect of the invention, amethodof 
electronic mail-based event scheduling includes the 
steps of receiving an electronic mail message sent by a 
sender to a predetermined event scheduling system ad- 
dress, parsing the electronic mail message to extract 
scheduling information therefrom, including event 
scheduler data, event data, resource data, and partici- 
pant data. The extracted scheduling information is 
stored in a predetermined format in a globally accessible 
record. The method then processes the scheduling in- 
formation in the globally accessible record and access 
schedule information stored in a schedule information 
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database, perform a function according to the data • 
therein, and prepare and send an outgoing electronic 
mail message to the sender and any affected event par- 
ticipant to acknowledge and report on the performed 
function. 5 
[0009] In yet another aspect of the invention, a meth- 
od of scheduling events using electronic mail includes 
the steps of preparing an electronic mail message con- 
taining scheduling information and sending it to a pre- 
determined event scheduling system address, receiving 10 
the electronic mail message and storing the electronic 
mail message in a message database, accessing the 
message database and parsing the received electronic 
mail message to extract scheduling information there- 
from. The scheduling information includes event sched- is 
uler data, event data, resource data, and participant da- 
ta. The method then includes the steps of storing the 
extracted scheduling information in a predetermined for- 
mat in a globally accessible record, and processing the 
scheduling information in the globally accessible record 20 
and accessing schedule information stored in a sched- 
ule information database, performing a function accord- 
ing to the data therein, and preparing and sending an 
outgoing electronic mail message to the sender and any 
affected event participant to acknowledge and report on 25 
the performed function. 

[0010] Atechnical advantage of thepresent invention 
is that the e-mail-based event scheduling system and 
method would optimally offer many of the features and 
components that are common to other computer based 30 
scheduling tools such as event reminder notification, a 
dedicated (non-email) graphical user interface and 
schedule presentation, security features, repetition and 
duration features (to handle a weekly meeting for a six 
month period for example), and many more. In addition 35 
to these capabilities, the system of the present invention 
offers the advantages and feature options that are a di- 
rect result of the e-mail based user interface. These ad- 
vantages include extending the reach of event schedul- 
ing beyond common system barriers that typically pre- 40 
vent or discourage remote tool usage without the need 
of special connection arrangements. Another advan- 
tage is that the inputting of scheduling data is not a sep- 
arate process since data is extracted from an e-mail 
event announcement message that would have been 45 
sent anyway. Furthermore, easy schedule validation/co- 
ordination capabilities avoids the tedious task of polling 
invitees for scheduling input, manually comparing 
schedules, or maintaining and using overlays that come 
with many scheduling tools. A further advantage is that so 
the user can enjoy the flexibility of using any of the many 
available e-mail clients to access the system of the 
present invention rather than being limited to one dedi- 
cated user interface and event scheduling application 
program. However, a dedicated user interface for the 55 
system of the present invention could still be provided 
to facilitate e-mail message composition. For example, 
a commonly available web browser-based graphical us- 



er interface may be used to allow the user to enter 
schedule information. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] For a better understanding of the present in- 
vention, reference may be made to the accompanying 
drawings, in which: 

FIGURES 1A through 1C are simplified block dia- 
grams of exemplary system configurations of the 
system and method of email-based event schedul- 
ing according to the teachings of the present inven- 
tion; 

FIGURE 2 is a block diagram of an embodiment of 
email message processing according to the teach- 
ings of the present invention; 
FIGURE 3 is a block diagram of another embodi- 
ment of email message processing according to the 
teachings of the present invention; 
FIGURES 4A through 4C are simplified block dia- 
grams of exemplary schedule information database 
configurations according to the teachings of the 
present invention; 

FIGURE 5 is a functional flow diagram of the system 
and method of email-based event scheduling ac- 
cording to the teachings of the present invention; 
FIGURE 6 is a functional flow diagram of an em- 
bodiment of a remote tool assistance according to 
the teachings of the present invention; 
FIGURE 7 is a flowchart of an embodiment of the 
remote tool assistance process according to the 
teachings of the present invention; 
FIGURE 8 is a functional flow diagram of an em- 
bodiment of an auto-scheduler process according 
to the teachings of the present invention; 
FIGURES 9 and 10 make up a flowchart of an em- 
bodiment of the auto-scheduler process according 
to the teachings of the present invention; 
FIGURE 1 1 is a functional flow diagram of the auto- 
scheduler process according to the teachings of the 
present invention; 

FIGURES 1 2 and 1 3 make up a flowchart of an em- 
bodiment of a conflict detector process according 
to the teachings of the present invention; 
FIGURE 14 is a flowchart of an embodiment of a 
schedule override process according to the teach- 
ings of the present invention; 
FIGURE 15 is a flowchart of an embodiment of an 
event cancellation process according to the teach- 
ings of the present invention; 
FIGURE 16 is a flowchart of an embodiment of an 
event confirmation process according to the teach- 
ings of the present invention; 
FIGURE 1 7 is a flowchart of an embodiment of an 
event withdrawal process according to the teach- 
ings of the present invention; 
FIGURE 18 is a flowchart of an embodiment of a 
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schedule report process according to the teachings 
of the present invention; 

FIGURE 19 is a flowchart of an embodiment of a 
remote tool preference setting process according to 
the teachings of the present invention; 5 
FIGURE 20 is an exemplary graphical user inter- 
face screen of an embodiment of service launcher 
according to the teachings of the present invention; 
and 

FIGURE 21 is an exemplary graphical user inter- 10 
face screen of an embodiment of an edit preferenc- 
es screen according to the teachings of the present 
invention. 



DETAILED DESCRIPTION OF THE INVENTION 15 

[0012] FIGURES 1A through 1C are simplified block 
diagrams of exemplary system configurations of the 
system and method of electronic mail-based event 
scheduling 1 0 according to the teachings of the present 20 
invention. System 10 operates with an e-mail system 14 
in order to access e-mail messages 1 6 and to allow sys- 
tem 1 0 to send e-mail messages 1 6. System 1 0 receives 
scheduling information and inquiries from users via an 
e-mail interface and also sends scheduling information 25 
to users via the e-mail interface. Therefore, users do not 
have to have access to system 1 0 via a dedicated inter- 
face and a terminal session as required by conventional 
scheduling tools. 

[0013] In FIGURE 1A, system 10 is operable to ac- 30 
cess a common message storage 12 which stores e- 
mail messages received by e-mail system 1 4. As shown 
in FIGURE 1 B, system 1 0 may operate with a common 
or existing e-mail system 14 that receives e-mail mes- 
sages and passes them on to system 10. System 10> 35 
also constructs e-mail messages and sends them via e- 
mail system 1 4. System 1 0 may also use or encompass 
a dedicated e-mail subsystem 14 that is part of system 
10, as shown in FIGURE 1C. 

[0014] FIGURE 2 is a block diagram of an embodi- 40 
ment of email message extraction process according to 
the teachings of the present invention. As an e-mail 
message is accessed by system 10, either received di- 
rectly from e-mail system 14 or by accessing common 
message storage 1 2, it is first processed by a message 45 
parser 20. Message parser 20 is responsible for exam- 
ining the contents of e-mail message 16 and extracting 
specific information stored in a global data structure 22, 
such as sender information (sender e-mail address), 
meeting information (location, date, starttime, endtime, 50 
description), associated resources (conference rooms), 
attendee information (attendee e-mail addresses), and 
one or more directives. The directives may include serv- 
ice directives, such as schedule an event, cancel an 
event, send remote tool assistance information, etc. ; re- 55 
sponse directives, such as how system 10 should re- 
spond if a schedule conflict is found; and preference di- 
rectives, such as to send mail in text or HTML (hypertext 



markup language) format. For example,the content of 
e-mail message 16 sent to system 10 to check a pro- 
posed event for schedule conflicts may include: 

To: sched tool@terasystems.com 
From: JohnDoe@terasystems.com 
Subject: Schedule test 

(Message Body) 

sched_test 

suggest_alt 

sched_on_pass 

text_mail 

Title: Protocol Enhancement Design Meeting 

Location: Conference Room 103 

Date: October 5, 1999 

Time: 9:00am-1 0:00am 

Invitees: 

Buddy Love, Richard Kimble, James Bond, Eddie 
Kruger, Mrs. Doubtfire, William Wallace, Jack Ryan 

Message parser 20 parses out and stores the data in 
the e-mail message according to global data structure 
22. Message parser 20 is operable to recognize prede- 
termined alphanumeric strings as directives. The direc- 
tives, sched_test, suggest_alt, sched_on_pass, text 
mail, shown in the email message examples above, di- 
rect system 10 to carry out a variety of functions per- 
formed by one or more system functions, such as secu- 
rity function 24, schedule suggester function 26, confir- 
mation function 28, meeting scheduler function 30, and 
meeting unscheduler function 32. For example, service 
directive u sched_tesf directs system 10 to check the 
schedule information database for scheduling conflicts. 
Response directive M suggest_aft n directs system 10 to 
suggest alternative scheduling solutions as a response 
to finding a scheduling conflict. A second response di- 
rective "sched_on_pass" directs system 10 to automat- 
ically schedule the meeting with all invitees if no conflict 
was found. Preference directive "text_mail" indicates 
that the user prefers to send e-mail messages in text 
format. Other examples of directive functionality include 
perform security checks on the e-mail message such as 
authenticating the message sender, outgoing message 
recipients, or doing a virus scan; update the schedule 
information database for all affected individuals and re- 
sources for new or cancelled events and send the as- 
sociated announcements; allow a user to withdraw from 
an event; reply with a schedule report for a user or re- 
source; update the schedule information database as a 
result of an invited user's confirmation to a specific 
event; update tool preferences for a user based on re- 
ceived directives; provide general tool usage informa- 
tion upon request or automatically upon receipt of a 
message which failed to meet the system format re- 
quirements. 

[0015] Global data structure is also referred to herein 
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as a globally accessiblerecord, which is-a f ile thatholds 
scheduling and other information extracted from an in- 
coming e-mail message directing system 1 0 to carry out 
certain functions. The format and structure of globally 
accessible record may vary according to implementa- 5 
tion. 

[0016] As an alternative to the message processing 
diagram shown in FIGURE 2, FIGURE 3 shows email 
message processing by dedicated parsers according to 
the teachings of the present invention. E-mail message 10 
1 6 is received and stored in a message storage data- 
base 34, which is accessible by a number of dedicated 
message parsers 36 to provide information to a number 
of functions 38. The stored e-mail message is therefore 
parsed and data extracted therefrom on an as needed is 
basis. For example, a scheduling tool control parser 40 
may access message storage 34 to extract information 
and directives related to scheduling and to provide the 
extracted data to a scheduling tool control function 42. 
A security parser 44 may parse the message and extract 20 
information and/or directives related to or needed by a 
security function 24. A meeting scheduler parser 46 may 
parse the message and extract information and/or di- 
rectives related to or needed by a meeting scheduler 
function 30. A schedule suggester parser 48 may parse 25 
the message and extract pertinent information and di- 
rectives for a schedule suggester function 26. A confir- 
mation information parser 50 may parse the message 
and extract pertinent information and directives for a 
confirmation function 28. A meeting unscheduler parser 30 
52 may parse the message and extract pertinent infor- 
mation and directives for a meeting unscheduler func- 
tion 32. 

[0017] FIGURES 4A through 4C are simplified block 
diagrams of exemplary schedule information database 35 
configurations according to the teachings of the present 
invention. Referring to FIGURE 4A t system 1 0 is shown 
sharing a common database 60 with existing applica- 
tions such as other scheduling tools 62. The database 
used by system 1 0 may be implemented in separate da- *o 
tabases, where one is devoted to storing common user 
or e-mail information 64 and shared with one or more 
other applications 66, and another database is devoted 
to storing common schedule information 68 and shared 
with one or more other applications 70, as shown in FIG- 45 
URE 4B. Alternatively, e-mail-based event scheduling 
system 1 0 may use a dedicated database 72 for storing 
e-mail messages, user information, scheduling informa- 
tion, and other information, as shown in FIGURE 4C. 
[0018] In particular, the schedule information data- so 
base of system 1 0 includes several types of records that 
can be accessed by system 1 0. Each record type may 
contain a logical set of related information. Some 
records contain references to other database records, 
which can be of a similar or different record type. For 55 
example, a user information record preferably contains 
information about the identity, preferences, and role or 
access privileges of each user authorized to use the. 



tool. The record may contain data fields such as- name, 
system user identity, user's role (tool administrator or 
common user), e-mail addresses, details about the e- 
mail addresses (input sending allowed, output receiving 
allowed, HTML or text preferred, etc.), individual prefer- 
ence settings and defaults to customize the tool behav- 
ior and environment, a list of resources thatthe user may 
schedule, and other possible information such as the us- 
er's host machine or the location of a user's schedule 
record(s). One possible variation from the above exam- 
ple is to have the list of resources that a user could 
schedule in a separate record of another possible record 
type, and have a data field in the user information record 
that contains references or pointers to one or more of 
these resource list records. This could conserve data- 
base space and possibly simplify resource association 
by allowing resource list records to be shared by multiple 
users that have a common group of resources that can 
be scheduled, such as all users in a certain building. 
[0019] The resource records preferably contain infor- 
mation about a resource that can be scheduled. The re- 
source record contains data fields for each resource, in- 
cluding name, capacity, restriction indicators (who has 
authorization to schedule, who can participate in events, 
etc.), name of the resource administrator, other possible 
resource attributes (teleconference capability, video 
conference capability, etc.), and the location of associ- 
ated schedule record(s). 

[0020] The schedule records are records that contain 
information about the schedule of a user or a resource. 
The information indicates the scheduled events and the 
affected time periods in the schedule. Schedule record 
may be implemented as one record that contains all 
schedule information for a user or resource. Schedule 
record may also be implemented such that each sched- 
ule record represents one event for a user or resource, 
where the records are used as an associated group 
(such as a linked list) to represent a schedule. The 
schedule records can contain event information or ref- 
erences to event records that contain event information. 
The start time, stop time, and event title for each event 
is contained in schedule records and/or an event 
records referenced by schedule records. 
[0021] An event record contains information about a 
specific event. Some implementations may not require 
the use of event records if the event information is in- 
cluded entirely in the schedule records. The event 
record may contain the start time, stop time, event title, 
and possibly an event description. Depending on the im- 
plementation, event records may also contain informa- 
tion such as a participant list, a confirmation flag for each 
participant, and pointers to affected schedule records. 
This information may be useful for implementations that 
support services that require multiple transactions relat- 
ed to a scheduled event. For example, if an event needs 
to be cancelled, an event record allows system 10 to 
quickly determine the affected users and resources. The 
associated schedule records can be located quickly and 
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-updated or deleted, whichever is applicable: If a user 
has his confirmation flag for a cancelled event set to the 
unconfirmed state, no database updates are necessary 
for that user since his schedule has not been updated 
to include the event. 

[0022] FIGURE 5 is a functional flow diagram of the 
system and method of email-based event scheduling 
according to the teachings of the present invention. As 
shown in FIGURE 5, e-mail message 16 initially enters 
e-mail system 14 and is stored in message storage 12 
that is accessible by the e-mail-based event scheduling 
system of the present invention. A main controller 42 of 
system 10 calls a new message check routine 80 that 
monitors message storage 1 2 and checks for new mes- 
sages. If one or more new messages are found, infor- 
mation is returned to main control program 42 about the 
location of the new messages. Main control program 42 
then passes the message location information to a virus 
checker routine 82. Virus checker routine 82 scans the 
new messages for software viruses and deletes any 
messages that contain a virus. Virus checker 82 may 
also perform virus clean up operations on system mem- 
ory. 

[0023] After checking the messages for viruses, virus 
checker 82 returns information to main control program 
42 about the status (clean or deleted) of each newly re- 
ceived message. Main control program 42 then calls a 
parser routine 20 to parse and extract information from 
each clean message. Parser routine 20 verifies that the 
e-mail message meets the predetermined format re- 
quirements to present information in a meaningful man- 
ner for system 1 0. Parser routine 20 builds a temporary 
working record or globally accessible record 22 that is 
accessible to system 10. Globally accessible record 22 
is a structure that contains information extracted from 
the e-mail message which may include the message 
sender, service directives, response directives, prefer- 
ence directives, event definition information (where, 
when, who), and other possible information. Parser 20 
returns information back to main controller 42 about the 
usability of each message and the location of its asso- 
ciated globally accessible record. Parser routine 20 may 
also be operable to set up default directives in globally 
accessible record 22 to direct the handling of an e-mail 
message that contains no directives. If parser 20 indi- 
cates that the e-mail message contains enough infor- 
mation to be usable to system 1 0, main control program 
42 may call a security routine 24. Security routine 24 
authenticates the required parsed information using in- 
formation from schedule information database 84 to en- 
sure that the message sender is an approved user. If 
any output messages are generated as a result of the 
e-mail message, the security routine authenticates the 
output recipients also by consulting schedule informa- 
tion database 84. Security program 24 may also add any 
required overhead information to globally accessible 
record 22 such as database pointers (in the case of a 
multiple database implementation) or schedule record 



location pointers for each involved user and resource. 
Security routine 24 then returns a validation report to 
main control program 42 to indicate whether the mes- 
sage information was successfully authenticated using 
5 schedule information database 84. At this point in the 
process, globally accessible record 22 contains enough 
data to meet the information requirements of all service 
routines of system 1 0. 

[0024] If security routine 24 indicates that the e-mail 

10 message has been authenticated, main control program 
42 continues processing based on the service directives 
found within the globally accessible record by calling the 
applicable service routines. Each service routine uses 
information from globally accessible record 22 to locate 

'5 schedule information database information required to 
perform that service. Database information may include 
names, e-mail addresses, schedule data records, user 
preferences, a set of resources that can be scheduled 
by each user, global or individual working period bound- 

20 aries (e.g., 8 A.M. to 5 P.M.), and any required overhead 
information such as database index records. 
[0025] After all of the requested services for a mes- 
sage have been processed, globally accessible record 
22 can be deleted because all information that needs to 

25 be retained is stored in database records. The functional 
flows of some possible service routines are described 
below. 

[0026] FIGURE 6 is a functional flow diagram of an 
embodiment of a remote tool assistance according to 
30 the teachings of the present invention. Remote tool as- 
sistance 86 is a possible service that replies with usage, 
format, syntax, and general usage information in re- 
sponse to an authenticated user. Remote tool assist- 
ance 86 may be invoked in response to a service direc- 
ts tive in a received e-mail message or as an automatic 
response to a received e-mail message that failed to 
meet the format requirements or contained too little in- 
formation. Recall that parser 20 is operable to access 
the e-mail message and extract the needed information. 
When main control program 42 detects the remote as- 
sistance service directive in the received e-mail mes- 
sage or determines that the e-mail message fails to pro- 
vide meaningful input, remote tool assistance 86 is 
called. Remote tool assistance 86 accesses schedule 
information database 84 to obtain the preferences of the 
message sender, and then generates an e-mail re- 
sponse message 1 6 to the sender that contains usage 
or help information. The e-mail response message may 
be sent directly by an e-mail subsystem 14 of system 
10 or via another e-mail application. The e-mail re- 
sponse message may be tailored to contain information 
specific the user, such as the user's preferences, re- 
source list, and default settings stored in schedule infor- 
mation database 84. Below is an example of an e-mail 
response message generated by remote tool assist- 
ance. 

To: JohnDoe@terasystems.com 
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Fromt sched tool@terasystems.com 
Subject: Re: Nonsense 

Common Service Directive Syntax: 
Service_directive_string [parm 1] [parm n] [parm last] 
[0027] Each service directive string must be con- 
tained on a separate line with no other text (except pa- 
rameters) within the e-mail message body. All service 
directive parameters must be included on the same line 
as the associated service directive string. 
[0028] Common Response Directive Syntax: 
[0029] Each response directive string must be con- 
tained on a separate line with no other text (except pa- 
rameters) within the e-mail message body. All response 
directive parameters must be included on the same line 
as the associated response directive string. Each re- 
sponse directive is associated with a specific service di- 
rective by its definition, and therefore, requires no spe- 
cial relative placement within the message body. 
[0030] Service Directive schedjest: 
[0031 ] Request schedule comparison of included par- 
ticipants and resources. 
[0032] Associated Response Directives: 
[0033] Suggest_alt: respond with alternative schedul- 
ing solutions for failed schedule validation (conflict de- 
tected) 

[0034] FIGURE 7 is a flowchart of an embodiment of 
the remote tool assistance process 86 according to the 
teachings of the present invention. Remote tool assist- 
ance 86 first reads the sender's name from the globally 
accessible record 22, as shown in block 88. The send- 
er's preferences and resource list are obtained from the 
schedule information database 84, as shown in block 
90. If remote tool assistance 86 was called as the result 
of a remote tool assistance service directive, as deter- 
mined in block 92, an email message with a customized 
report is generated and sent that includes the tool usage 
syntax and information, the sender's tool preference 
settings, the sender's resource list, and other possible 
data that could assist the sender with using the tool, as 
shown in block 94. If remote tool assistance 86 was 
called as the result of a received email message that is 
unusable by the tool, as determined in block 92, and the 
sender's preference setting indicates that customized 
tool assistance information be included in the error mes- 
sage response, as determined in block 98, an email 
message with a customized report is generated and 
sent, as shown in block 94. If the sender does not prefer 
to include customized tool help information in the error 
response, as determined in block 98, an email message 
containing a basic error response is generated and sent, 
as shown in block 100. After sending the applicable 
email message response to the sender, the process re- 
turns to the main controller, as shown in block 96. 
[0035] FIGURE 8 is a functional flow diagram of an 
embodiment of an auto-scheduler process 110 accord- 
ing to the teachings of the present invention. Auto- 
scheduler 110 is invoked by receiving an e-mail mes- 



sage that contains an auto-schedule service. directive,- 
a time window, a list of invited individuals, an optional 
list of resources (locations), and an event title and/or de- 
scription. Main control program 42 calls auto-scheduler 
5 1 1 0 as directed by the service directive stored in globally 
accessible record 22. Auto-scheduler 110 uses sched- 
ule information database 84 to cross check the availa- 
bility of the invited individuals and the allowable resourc- 
es for the specified time window until a solution is found. 
10 Upon the determination of a successful solution, auto- 
scheduler 110 updates every invitee's schedule in 
schedule information database 84, schedules the re- 
source, and sends out the event announcements with 
the date/time, location, list of invitees, and event de- 
*5 scription. Auto-scheduler 11 0 frees the user from having 
to manually compare the schedules of resources and 
individuals to arrive at a event schedule. Auto-scheduler 
may be set up as the default service for a user that is 
applied to a received message with no service directive. 

20 Default resources and time window values may also be 
used when these are not included in the e-mail mes- 
sage. For example, a received e-mail message that only 
has an invitation list could be processed as shown in 
FIGURE 8. Parser routine 20 fails to find an event title 

25 or description in the body of the e-mail message so it 
assumes that the e-mail subject is the event title while 
building globally accessible record 22. Parser 20 also 
fails to find any directives so it uses the default direc- 
tives, which may have been configured on an individual 

30 or global basis. After parser 20 completes constructing 
globally accessible record 22, main control program 42 
checks globally accessible record 22 and finds the de- 
fault service directive (auto-schedule in this case) 
placed there by parser routine 20. 

35 [0036] FIGURES 9 and 1 0 make up a flowchart of an 
embodiment of the auto-scheduler process 110 accord- 
ing to the teachings of the present invention. Referring 
to FIGU RE 9, main control program 42 calls auto-sched- 
uler 1 1 0 which first checks globally accessible record 22 

40 for resource information, as shown in block 112. If no 
resource information is found, auto-scheduler 110 ac- 
cesses schedule information database 84 to obtain the 
user's default resource information. Auto-scheduler 110 
then checks globally accessible record 22 for a specific 

45 time window and event duration, as shown in block 1 1 6. 
If none is found, auto-scheduler 110 obtains the user's 
default time window information from schedule informa- 
tion database 84, as shown in block 1 1 8. Auto-scheduler 
1 1 0 may determine that the default start time is the first 

so hour boundary after 24 hours from the current time, for 
example. In the example shown in FIGURE 1 1 , the mes- 
sage was received at 7:43 A.M. so the window start time 
is 8:00 A.M. the next day. Since no end time was spec- 
ified, auto-scheduler may use the user's default period 

55 of one hour stored in schedule information database 84, 
and sets the end time to be one hour after the start time. 
Therefore, the start time and end time of the first period 
in the time window is determined, as shown in block 1 20. 
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Auto-scheduler 110 then checks the schedule of-each 
invited individual for conflicts during the time period de- 
fined by the start time and end time, as shown in blocks 
122-128. If one or more individuals is not available dur- 
ing this hour, auto-scheduler 1 1 0 then increments both 5 
the start time and end time by one hour (while respecting 
normal work hour boundaries), as shown in block 130. 
The process continues until a period is found that is un- 
scheduled by all of the invitees in block 134. 
[0037] Referring to FIGURE 10, auto-scheduler 110 10 
continues with resource scheduling 134. If no resource 
is listed, auto-scheduler 110 checks each resource 
(conference rooms in this case) associated with the 
sender as specified in schedule information database 
84 until a resource is found that is available for that pe- 15 
riod, as shown in blocks 140-146. If none is available 
during that period, the start time and end time are incre- 
mented again in block 130 in FIGURE 9 to check for 
participant schedule conflicts with the new time. Partic- 
ipant schedule checking and resource schedule check- 20 
ing are performed in this manner until a schedule solu- 
tion is found as shown in FIGURE 11 , or until the spec- 
ified time window or a quit searching limit, if any, is ex- 
ceeded, as determined in block 156. If no solution is 
found, an e-mail message is constructed to inform the 25 
sender that no scheduling solution was found in the time 
window, as shown in block 1 60. This message is sent 
to the sender. 

[0038] Once a solution is found, an announcement e- 
mail message is built and sent to the sender (if not spec- 30 
ified as self excluded) and invited individuals, as shown 
in block 148. The announcement e-mail message con- 
tains the event title, location, date, start time, end time, 
and a unique event identifier. The database schedule 
records for the scheduled resource and invited individ- 35 
uals (if allowed) are updated as well, as shown in blocks 
150 and 152. 

[0039] The event identifier is an event identification 
mechanism which may be an alphanumeric string that 
is assigned as part of the event scheduling process. 40 
Each event scheduled by system 1 0 has an event record 
stored in the database that contains enough information 
to locate all other database records (for the individuals 
and/or resources) related to that event. The unique 
event identifier is used by system 1 0 to locate the event 45 
record. The unique event identifier is included in the e- 
mailed event announcements so that users may use it 
to refer to a particular event in any later transactions re- 
lated to that event. 

[0040] An additional design consideration is to have so 
a capacity indicator for each resource in schedule infor- 
mation database 84. The capacity indicator is used as 
a factor in the auto-scheduling process. For example, if 
the resource has capacity to support an event involving 
ten or less individuals, and eleven or more participants 55 
are associated with the event, that resource is eliminat- 
ed as a resource candidate for this event. 
[0041 ] One possible preference directive is to be setf- 



excluded from scheduled events. This allows an event 
scheduler such as a secretary or resource administra- 
tors who is not an event participant to schedule events 
using system 10. This avoids causing false scheduling 
conflicts that could occur for an individual who performs 
event scheduling on the behalf of others. 
[0042] Conflict detector 190 of the present invention 
performs the schedule comparison work for the user. 
This is useful when a would-be event scheduler wants 
to validate a specific event that is to be scheduled at a 
certain time or any of a number of sporadic time periods. 
Conflict detector 1 90 may be invoked by sending e-mail 
messages to system 1 0 containing specific inf ormation 
for a proposed event and then checking the pass/fail re- 
sponse generated by conflict detector 1 90 until a sched- 
ule solution is found ("schedule fishing"). Therefore, 
conflict detector 1 90 provides the user more control than 
the auto-scheduler service. Another use for this service 
is to determine the number of conflicts that a scheduled 
event will produce. This is helpful when an event that 
involves a large audience is being planned, and it would 
be impossible to find a time slot that produces no sched- 
ule conflicts. Conflict detector 1 90 may be instructed to 
generate a report that suggests a time slot that would 
produce the least amount of conflicts to existing sched- 
ules. 

[0043] FIGURES 12 and 13 make up a flowchart of 
an embodiment of a conflict detector process 190 ac- 
cording to the teachings of the present invention. If an 
e-mail message contains a conflict detector service di- 
rective, main control program 42 calls conflict detector 
190. Conflict detector 190 uses the event information in 
globally accessible record 22 associated with the mes- 
sage to check for the availability of all affected partici- 
pants (invitees) and resources (conference room, labs, 
etc.) during the indicated time period. The end result of 
the conflict detector service depends on the validation 
outcome and any included response directives. 
[0044] Referring to FIGURE 12, in block 1 92, a con- 
flict counter is initialized to zero (0). Conflict detector 1 90 
then checks the first participant's schedule record in 
schedule information database 84 for conflict during the 
specified period, as shown in block 194. If a schedule 
conflict is found, as determined in block 196, then the 
conflict counter is incremented in block 198. In block 
200, a determination is made as to whether the user had 
indicated in a directive that he/she desires to know the 
number of conflicts found by conflict detector 1 90. If the 
user does desire this information, then in block 204, a 
check as to whether the last participant in the event has 
been reached. If there are still more participants to 
check, then the next participant's schedule record is 
checked for conflicts, as shown in block 206, and the 
process returns to block 196. If on the other hand the 
last participant has been reached, then whether the con- 
flict counter value is zero is determined in block 208. If 
the conflict counter value is zero, then it is indicative that 
no conflict with any participant's schedule was found 
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and the event time specified by the e-mail message- 
sender is suitable for the specified event. In block 210, 
conflict detector determines whether a schedule re- 
sponse directive is contained in the received e-mail 
message. If such a directive is present, then a schedule 5 
override process is called to update the schedule 
records of the participants and resources to schedule 
the event, as shown in block 212. An e-mail message 
announcing the scheduled event is also sent to all par- 
ticipants. If the schedule response directive is not 10 
present in the received e-mail message, then an outgo- 
ing e-mail message is constructed to inform the received 
e-mail message sender that no conflict was found. The 
sender may then choose to send an e-mail message to 
system 10 to schedule the event. If, in block 208, it is '5 
determined that the conflict counter value is not zero, 
then an outgoing e-mail message is built containing a 
report on the schedule conflicts and the number of con- 
flicts found, as shown in block 220. The process then 
returns to the main controller in block 214. 20 
[0045] If, in block 200, it is determined that the number 
of conflicts is not sought out by the original e-mail send- 
er, then execution proceeds to block 202 in FIGURE 13. 
In block 230, it is determined whether schedule re- 
sponse directives, such as to suggest alternative sched- 25 
uling solutions, are found in the received e-mail mes- 
sage. If found, then the start time and end time of the 
specified period is incremented by an amount previously 
specified by the sender's preference, as shown in block 
232. The first participant's schedule record is checked 30 
for conflicts during the new period, as shown in block 
234. If a schedule conflict is found, as determined in 
block 236, then the start and end times of the time period 
is again incremented, as shown in block 232. This is re- 
peated until no schedule conflict is found in block 236. 35 
If the participant is not the last participant in the globally 
accessible record, as determined in block 238, then the 
next participant's schedule record in the schedule infor- 
mation database is checked until all participants' sched- 
ules have been checked for conflicts. When the last par- 40 
ticipant's schedule has been checked and no conflict 
has been found for any of the participants with respect 
to the current proposed time period, then the schedule 
information database is checked for resource conflicts, 
as shown in block 242. If a schedule conflict was found 45 
for resources, as determined in block 244, then it is de- 
termined in block 250 whether the current period is the 
last period to be checked based on predetermined quit 
limits or user prescribed length of time in which to check. 
If the limit has not been reached, then execution loops so 
back to block 232 to check the next time period. Other- 
wise, an e-mail message containing information that no 
alternative scheduling solution were found is prepared 
and sent to the sender of the received e-mail message, 
as shown in block 252. If in block 244, it is determined 55 
that no resource schedule conflict exists, then an e-mail 
message informing the sender of the alternative sched- 
uling solution is prepared and sent via the e-mail sys- 



tem, as shown in block 246. Conflict detector then ends 
and execution returns to the main control program, as 
shown in block 248. 

[0046] In addition to requesting alternative scheduling 
solutions, the response directive examined in block 230 
may also request the resulting number of conflicts that 
would occur for the proposed event. The response di- 
rective could also simply request that response e-mail 
message be returned indicating that a conflict was found 
or not found. 

[0047] FIGURE 14 is a flowchart of an embodiment of 
a schedule override process 260 according to the teach- 
ings of the present invention. Schedule override 260 al- 
lows a user to schedule an event via e-mail regardless 
of schedule conflicts. This is useful for scheduling a high 
priority event. With this service, the user sends the an- 
nouncement to the tool with the schedule override serv- 
ice directive. Main control program 42 calls the schedule 
override routine 260, which automatically sends the an- 
nouncements and updates the schedule database for 
the scheduled resource and individuals (if allowed). 
[0048] Referring to FIGURE 14, schedule override 
process 260 checks if information it needs to perform 
this service is present in the globally accessible record, 
as shown in block 262. If not, then schedule override 
260 accesses the e-mail message sender's preferences 
from the scheduling information database, as shown in 
block 264. The sender's preference is then examined to 
determine whether the sender prefers remote tool as- 
sistance along with a notification of error in a response 
e-mail message, as shown in block 272, and an e-mail 
message is built according to the sender's preference 
and sent to the sender via the e-mail system, as shown 
in blocks 268 and 272. Execution then returns to the 
main control program, as shown in block 270. 
[0049] If, in block 262, it is determined that the re- 
quired information is found in the globally accessible 
record, then an e-mail message is constructed and sent 
to notify each event participant, as shown in block 276. 
Schedule override 260 then updates the schedule 
record of each participant to add this event, as shown 
in block 278. However, a participant's schedule is up- 
dated or modified only if the user allows it. These users 
may choose, as indicated by their preferences, to permit 
such schedule update only after their confirmation. For 
these individuals, they may confirm the change by sim- 
ply replying back to the event announcement. System 
10, upon receipt of this reply message, determines that 
it is a confirmation for an event schedule and updates 
the schedule accordingly. 

[0050] FIGURE 15 is a flowchart of an embodiment of 
an event cancellation process 290 according to the 
teachings of the present invention. The event cancel 
service allows an event to be cancelled via an e-mail 
message. The user sends an e-mail message to system 
10 with an event cancel service directive and enough 
information to identify an event, such as a unique event 
identifier that is assigned to each scheduled event. The 
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main control program calls the event-cancel routine as 
a result of the event cancel service directive. Event can- 
cel routine 290 first looks for the event identifier in the 
globally accessed record, as shown in block 292. If the 
event identifier is found, then the event identifier is used 5 
to locate the event record associated with the scheduled 
event in the schedule information database, as shown 
in block 294. Event canceller 290 then determines, by 
examining the event record, whether the sender of the 
event cancellation e-mail message is the scheduler or 10 
a participant of the event, as shown in block 306. If the 
sender is not the scheduler or a participant of the event, 
event canceller 290 may bar the message sender from 
canceling the event absent directives indicating that this 
sender has the authority to do so. An e-mail message 1$ 
containing a negative acknowledgment is then con- 
structed to inform the message sender that he/she is not 
permitted to cancel this event and sent to the sender via 
the e-mail system, as shown in block 308. The execution 
then returns to the main control program in block 304. 20 
[0051] If the sender of the event cancellation mes- 
sage is allowed to cancel the described event, as deter- 
mined in block 306, event canceller locates and updates 
the affected database records for resource and partici- 
pants, and sends the cancellation announcements via 25 
the e-mail system, as shown in blocks 310 and 312. 
[0052] If, in block 292, it is determined that the event 
identifier is not found in the globally accessible record, 
then the schedule information database may be 
searched to locate a schedule event that matched the 30 
event information that are found in the globally accessi- 
ble record, as shown in block 296. If the event is found, 
as determined in block298, then the event identifier con- 
tained in the resource schedule record is used to locate 
the event record in the database, as shown in blocks 35 
300 and 294. If the event cannot be located, then an e- 
mail message is constructed and sent to the sender of 
the event cancellation message to inform him/her of this 
fact. 

[0053] FIGURE 1 6 is a flowchart of an embodiment of 40 
an event confirmation process 320 according to the 
teachings of the present invention. Event confirmation 
service 320 allows a user to control updates to their 
schedule record(s) by only allowing events to be self- 
scheduled either directly or as a result of confirming an 45 
invitation to an event. First, the user enables this option 
as a preference either by sending an e-mail message 
with the appropriate preference directive and parameter 
(s). When an event is scheduled with the event confir- 
mation service enabled, the user receives an e-mailed so 
announcement as always, butthe database remains un- 
affected until the user replies to the e-mailed announce- 
ment. 

[0054] When the user with the event confirmation 
service preference enabled, the event invitation or an- 55 
nouncement contained in the user's reply thereto in- 
cludes the event identifier. When system 1 0 receives the 
reply, the main control program calls event confirmation 



routine 320: Event confirmation -routine 320 uses the ™ 
unique event identifier in the e-mail message (and later 
stored in the globally accessible record) to locate the 
particular event record, as shown in blocks 322 and 324. 

5 The information from the event record is then used to 
locate and update the reply message sender's schedul- 
ing record for this event if the sender's event confirma- 
tion flag is set to unconfirmed state for this event, as 
shown in blocks 336 and 338. The event confirmation 

10 flag for the particular event is then set, as shown in block 
338. The user's event confirmation flag is set to prevent 
the generation of additional schedule records related to 
this event for this user caused by any inadvertently-sent 
duplicative reply. The event confirmation flag is also 
15 used by system 1 0 to determine which schedule records 
are in need of update in the case of a cancelled event. 
[0055] If the event identifier is not found in the globally 
accessible record as determined in block 322, the 
schedule records of affected resources for this event is 
20 searched to identify the event, as shown in block 326. 
If the event cannot be identified, then an e-mail message 
containing a negative acknowledge is constructed and 
sent to the sender, as shown in block 332. Execution 
then returns to the main control program, as shown in 

6 block 334. 
[0056] FIGURE 1 7 is a flowchart of an embodiment of 
an event withdrawal process 350 according to the teach- 
ings of the present invention. Event withdraw service 
350 allows a user to remove a scheduled event from his 

?0 own schedule by sending system 10 an e-mail mes- 
sage. The e-mail message contains an event withdraw 
service directive and sufficient information to identify an 
event such as the event identifier. The main control pro- 
gram calls event withdraw routine 350 as a result of de- 
*s tecting the event withdraw service directive. In block 
352, event withdraw process 350 looks for the unique 
event identifier in the globally accessible record. If the 
event identifier is not found, then the schedule record of 
the affected resource for the event are searched to iden- 
k> tify the event, as shown in block 354. If the event is still 
not found, a negative acknowledgement contained in an 
e-mail message is sent to the sender of the event with- 
draw message, as shown in block 362. If the event can 
be identified from the resource schedule records, the 
w event identifier is obtained and used to continue 
processing the event withdraw e-mail message, as 
shown in block 358. 

[0057] Event withdraw routine 350 uses the event 
identification information from the message in the glo- 
0 bally accessible record to locate the related event 
record, as shown in block 360. Event withdraw 350 first 
verifies that the sender of the message is a participant 
in the event, as shown in block 366. If not, an e-mail 
message is prepared and sent to the sender of the event 
5 withdraw message to notify the sender that he/she is not 
a participant of the identified event, as shown in block 
368. 

[0058] If the sender is a participant, then the event 
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record is used to locate the schedule record ofthis send- 
er, which is then updated to delete the event therefrom, 
as shown in blocks 370 and 372. A positive acknowl- 
edgement e-mail message is then sent to the sender 
and the event scheduler, if they are different individuals, 5 
via the e-mail system, as shown in block 374. The event 
record for the event is also updated to remove the send- 
er as a participant in this event, as shown in block 376. 
Execution then returns to the main program, as shown 
in block 364. io 
[0059] FIGURE 1 8 is a flowchart of an embodiment of 
a schedule report process 390 according to the teach- 
ings of the present invention. Schedule report service 
390 allows a user to obtain his/her own schedule, re- 
source schedule information, or schedule information is 
for another user (if authorized) via an e-mail message. 
The service is invoked by sending an e-mail message 
to system 1 0 that includes a schedule report service di- 
rective and some optional associated parameters. The 
main control program calls schedule report routine 390 20 
as directed by the service directive. Schedule report rou- 
tine 390 first checks the user parameters associated 
with the schedule report service directive in the globally 
accessible record, as shown in block 392. If the user 
parameters Indicate that the requested report is for an- 25 
other user or a resource, as determined in block 394, 
the schedule report routine determines whether the as- 
sociated privacy settings allow that information to be re- 
ported to this user (the message sender), as shown in 
blocks 396 and 398. If no user or resource parameters 30 
were specified, as determined in block 392, the sched- 
ule of the sender is assumed, as shown in block 404. If 
schedule reporter 390 determines that this schedule in- 
formation can be mailed to the requester (report request 
message sender), as determined in block 41 2, it gener- 35 
ates a schedule report from the database records for the 
specified time period specified in the schedule report e- 
mail message (and stored in the globally accessible 
record) or a default period, as shown in blocks 406-41 0. 
Events may also have individual privacy settings. In this 40 
case, any schedule record for a private event is only in- 
cluded in a report sent to the record owner, as shown in 
blocks 412 and 414. 

[0060] The schedule report service may be set up by 
the user to occur automatically on a periodic basis (such 45 
as sending a weekly agenda every Sunday night), or 
prepared and sent on demand. 
[0061] FIGURE 19 is a flowchart of an embodiment of 
a remote tool preference setting process 440 according 
to the teachings of the present invention. E-mail-based so 
event scheduling system 1 0 offers many preferences for 
each individual user. E-mail messages may be used to 
remotely change the preferences for a user. For exam- 
ple, the user may include a preference directive within 
an e-mail message to direct the tool to send all future 55 
mail to this user in HTML or text format. The preference 
directive can be sent to the tool in a dedicated e-mail 
message, or included in a message that invoked other 



services. Preference directives can be thought of as 
service directives that only affect user preference set- 
tings and defaults rather than invoking services. When 
system 1 0 processes a preference directive, it calls the 
remote tool preference setting routine 440. In block 442, 
the first preference directive is read from the globally 
accessible record. The validity of the parameters for the 
preference directive is checked, as shown in block 444. 
If the preference directive is valid, as determined in 
block 446, then the preference update description is 
added to a positive feedback report, as shown in block 
448, and the preference indicators and default data are 
updated in the message sender's record, as shown in 
block 450. If the preference directive is not valid, then 
the description of this preference directive is added to a 
negative feedback report, as shown in block 452. In 
block 454, the globally accessible record is checked to 
determine whether all preference directives have been 
processed. If not, execution loops back to block 442 to 
process the next preference directive. If all the prefer- 
ence directives have been processed, the positive and 
negative feedback reports are formatted as specified by 
the user's updated preferences, if applicable, and sent 
to the user in a manner according to the user's updated 
preferences, as shown in blocks 456 and 458. Execution 
then returns to the main control program, a shown in 
block 460. 

[0062] Below is a list of some possible preferences 
that could be updated remotely: 

- Send all future mail to this user in HTML format, 
Text format, or both 

- Add new e-mail address for the user 

- Delete an e-mail address for the user (the user 
must have at least one remaining e-mail address) 

- Change the default receiving e-mail address for 
the user 

- Set the default schedule report period parameter 
(such as today plus six days, this month, this week, 
today only) 

- Start, stop, or modify an automatic periodic sched- 
ule report 

- Change normal work day boundaries (dont sched- 
ule weekends, or between 6:00 P.M. and 8:00 A.M. 
weekdays, or between noon and 1:00 P.M. week- 
days) 

- Start, stop, or set up a vacation response for a 
specified period 

- Set the default auto-schedule event duration (such 
as half hour, one hour, or two hours) 
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- Set the default auto-schedule start (such as next 
hour boundary, next half hour boundary, next hour 
boundary plus 24 hours, next hour boundary plus 
48 hours, etc.) 

- Set the default auto-schedule quit limit (give up 
and notify user if no solution found in one week, two 
weeks, N days, etc.) 

- Set the preferred date/time formats (for announce- 
ments sent to user from the tool) 

- Set the preferred error response behavior (send 
remote tool assistance information or just a nega- 
tive acknowledgement) 

[0063] Many computers that host an e-mail client ap- 
plication also host an internet browser application, such 
as MS Internet Explorer® or Netscape Navigator®. 
Therefore, e-mail-based event scheduling system and 
method may include an associated CGI program and 
browser form that functions as a template to help users 
generate an e-mail message that meets the format and 
syntax requirements of system 10. 
[0064] FIGU RE 20 is an exemplary graphical user in- 
terface screen of an embodiment of the service launcher 
according to the teachings of the present invention. A 
web browser form, such as the example shown in FIG- 
URE 20, can provide text entry fields that are each ded- 
icated to a particular message item such as the event 
title, event description, event location, scheduler, and 
list of participants. For message items that have a lim- 
ited set of possible values such as start time, end time, 
service directives, and response directives, the use of 
controls (buttons, switches, and menus) may be utilized. 
Controls limit the user input choices to logical combina- 
tions such as only presenting the response directive 
choices that are associated with the concerned service 
directive. Controls can also enforce formatting such as 
for date/time information. 

[0065] After completing the form, the user submits the 
form by clicking the Submit button. The form may con- 
tain logic to respond with an error message for certain 
error conditions such as missing datafora required data 
field or a start time that is later than the end time. When 
the form is submitted successfully, the data is passed to 
a CGI program, which generates the e-mail message 
based on the form data, and sends it, via the e-mail sys- 
tem, to the main control program of system 10. System 
10 processes browser-generated e-mail messages like 
all others. 

[0066] It is also possible to have the browser form dis- 
play information stored in the schedule information da- 
tabase. For example, if a user clicks on the Edit Prefer- 
ences button on the form shown in FIGURE 20 after typ- 
ing his name in the Scheduler field, a new form appears 
such as shown in FIGURE 21 . This form displays current 
preferences and defaults for the user/scheduler. The us- 



• er can examine and modify his/her current- preferences 
using this form. Once again, when the form is submitted, 
the data is passed to a CGI program, which generates 
the e-mail message containing preference directives 

s based on the form data, and sends it to system 1 0 to be 
processed. 

[0067] Although several embodiments of the present 
invention and its advantages have been described in de- 
tail, it should be understood that mutations, changes, 
10 substitutions, transformations, modifications, varia- 
tions, and alterations can be made therein without de- 
parting from the teachings of the present invention, the 
spirit and scope of the invention being set forth by the 
appended claims. 

15 

Claims 

1 . An electronic mail-based event scheduling system, 
20 comprising: 



a message parser accessing an electronic mail 
message received from a sender, extracting 
scheduling information therefrom, and storing 
the extracted scheduling information in a pre- 
determined format in a globally accessible 
record; 

the globally accessible record storing extracted 
scheduling information including event sched- 
uler data, event data, resource data, and par- 
ticipant data; 

a schedule information database; and 
an event processing function accessing the glo- 
bally accessible record and the schedule infor- 
mation database, function according tothe data 
therein, and preparing and sending an outgoing 
electronic mail message to the sender and any 
affected event participant to acknowledge and 
report on the performed function. 



25 



30 



40 



2. The system, as set forth in claim 1, wherein the 
event processing function comprises an event 
scheduler accessing the globally accessible record, 
scheduling an event according to the extracted 

4 5 scheduling information, and storing information as- 
sociated with the scheduled event in the schedule 
information database, the event scheduler further 
preparing and sending an outgoing electronic mail 
message to the sender and any affected event par- 

50 ticipant to acknowledge and report the scheduled 
event. 

3. The system, as set forth in claim 2, wherein the 
schedule information database comprises: 



55 



a user schedule record for each user of the sys- 
tem containing scheduled events for the user; 
and 
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a resource schedule record for each resource 
containing scheduled events for the resource. 

4. The system, as set forth in claim 2, wherein the 
schedule information database comprises a user in- 5 
formation record for each user of the system con- 
taining user identity, preferences, and access priv- 
ileges of the user. 

5. The system, as set forth in claim 2, wherein the 10 
schedule information database comprises an event 
record for each scheduled event containing an 
event identifier, event time data, participant data, 
and resource data. 

15 

6. The system, as set forth in claim 1, wherein the 
event processing function comprises an auto- 
scheduler accessing the globally accessible record, 
obtaining a time window, checking for scheduling 
conflicts within the time window with the participants 20 
and resources, scheduling an event by storing 
event data in the schedule information database, 
and preparing and sending an electronic mail mes- 
sage to each event participant announcing the 
scheduled event. 25 

7. The system, as set forth in claim 1 , wherein the 
event processing function comprises a conflict de- 
tector accessing the globally accessible record, ob- 
taining a time period, checking for scheduling con- 30 
flicts within the time period with the participants and 
resources, and preparing and sending an electronic 
mail to the sender reporting scheduling conflict da- 
ta. 

35 

8. The system, as set forth in claim 1, wherein the 
event processing function comprises a schedule 
overrider accessing the globally accessible record, 
scheduling an event by storing event data in the 
schedule information database regardless of partic- 40 
ipant schedule conflict, and preparing and sending 

an electronic mail message to each event partici- 
pant announcing the scheduled event. 

9. The system, as set forth in claim 1 , wherein the 45 
event processing function comprises an event can- 
celler accessing the globally accessible record, re- 
moving the scheduled event from the schedule in- 
formation database, and preparing and sending an 
electronic mail message to each event participant so 
announcing event cancellation. 

10. The system, as set forth in claim 1, wherein the 
event processing function comprises an event con- 
firmer accessing the globally accessible record, lo- 55 
eating, in the schedule information database, data 
associated with the scheduled event described 
therein, confirming the sender's participation in the 



— • scheduled. eventrand preparing and sending an 
electronic mail message to the sender acknowledg- 
ing and reporting the event confirmation. 

11. The system, as set forth in claim 1, wherein the 
event processing function comprises an event with- 
draw process accessing the globally accessible 
record, locating, in the schedule information data- 
base, data associated with the scheduled event de- 
scribed therein, removing the sender as a partici- 
pant in the scheduled event, and preparing and 
sending an electronic mail message to the sender 
acknowledging and reporting the event withdrawal. 

12. The system, as set forth in claim 1, wherein the 
event processing function comprises a schedule re- 
porter accessing the globally accessible record, lo- 
cating, in the schedule information database, 
schedule data associated with the sender, and pre- 
paring and sending an electronic mail message to 
the sender containing the user's scheduled events. 

13. The system, as set forth in claim 1, wherein the 
event processing function comprises a remote pref- 
erence setter accessing the globally accessible 
record, locating, in the schedule information data- 
base, preference data associated with the sender, 
updating the sender's preference data in the sched- 
ule information database, and preparing and send- 
ing an electronic mail message to the sender report- 
ing on the success and failure of preference up- 
dates. 

14. The system, as set forth in claim 1, wherein the 
event processing function comprises a remote tool 
assistance accessing the globally accessible 
record, locating, in the schedule information data- 
base, preference data associated with the sender, 
and preparing and sending an electronic mail mes- 
sage to the sender containing help information in 
response to the data in the globally accessible 
record and the preference data. 

1 5. The system, as set forth in claim 1 , further compris- 
ing: 

a message database storing electronic mail 
messages destined for the system sent by the 
sender; and 

a new message checker scanning the message 
database for new messages. 

16. The system, as set forth in claim 15, further com- 
prising a virus checker checking for electronic virus- 
es in the electronic mail messages in the message 
database. 

17. The system, as set forth in claim 15, further com- 
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prising a security checker verifying that the sender 
is an authorized user of the system. 

18. The system, as set forth in claim 1 , further compris- 
ing a browser-based graphical user interface hav- 5 
ing a data entry form operable to receive user input 
and prepare an electronic mail message containing 
the user input according to predetermined syntax 
and format requirements. 

10 

19. A method of electronic mail-based event schedul- 
ing, comprising: 

receiving an electronic mail message sent by a 
sender to a predetermined event scheduling 15 
system address; 

parsing the electronic mail message to extract 
scheduling information therefrom, including 
event scheduler data, event data, resource da- 
ta, and participant data; 20 
processing the extracted scheduling informa- 
tion and accessing schedule information stored 
in a schedule information database, performing 
a function according to the data therein, and 
preparing and sending an outgoing electronic 25 
mail message to the sender and any affected 
event participant to acknowledge and report on 
the performed function. 

20. The method, as set forth in claim 19, wherein 30 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
scheduling an event according to the extracted 35 
scheduling information; 
storing information associated with the sched- 
uled event in the schedule information data- 
base; and 

preparing and sending an outgoing electronic 40 
mail message to the sender and any affected 
event participant to acknowledge and report the 
scheduled event. 

21. The method, as set forth in claim 19, wherein 45 
processing the scheduling information comprises: 

accessing a globally accessible record storing 

extracted scheduling information; 

obtaining a time window; so 

checkingforschedulingconflicts within the time 

window with the participants and resources; 

scheduling an event by storing event data in the 

schedule information database; and 

preparing and sending an electronic mail mes- 55 

sage to each event participant announcing the 

scheduled event. 



22. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
obtaining a time period; 
checking for scheduling conflicts within the time 
period with the participants and resources; and 
preparing and sending an electronic mail to the 
sender reporting scheduling conflict data. 

23. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
scheduling an event by storing event data in the 
schedule information database regardless of 
participant schedule conflict; and 
preparing and sending an electronic mail mes- 
sage to each event participant announcing the 
scheduled event. 

24. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
removing the scheduled event from the sched- 
ule information database; and 
preparing and sending an electronic mail mes- 
sage to each event participant announcing 
event cancellation. 

25. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
locating, in the schedule information database, 
data associated with the scheduled event de- 
scribed therein; 

confirming the sender's participation in the 
scheduled event; and 

preparing and sending an electronic mail mes- 
sage to the sender acknowledging and report- 
ing the event confirmation. 

26. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
locating, in the schedule information database, 
data associated with the scheduled event de- 
scribed therein; 

removing the sender as a participant in the 
scheduled event; and 
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-preparing and sending an electronic mail mes- 
sage to the sender acknowledging and report- 
ing the event withdrawal. 

27. The method, as set forth in claim 19, wherein 5 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 
locating, in the schedule information database, 10 
schedule data associated with the sender; and 
preparing and sending an electronic mail mes- 
sage to the sender containing the user's sched- 
uled events. 

75 

28. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 

accessing a globally accessible record storing 
extracted scheduling information; 20 
locating, in the schedule information database, 
preference data associated with the sender; 
updating the sender's preference data in the 
schedule information database; and 
preparing and sending an electronic mail mes- 25 
sage to the sender reporting on the success 
and failure of preference updates. 

29. The method, as set forth in claim 19, wherein 
processing the scheduling information comprises: 30 

accessing a globally accessible record storing 

extracted scheduling information; 

locating, in the schedule information database, 

preference data associated with the sender; 35 

and 

preparing and sending an electronic mail mes- 
sage to the sender containing help information 
in response to the data in the globally accessi- 
ble record and the preference data. 40 

30. The method, as set forth in claim 19, further com- 
prising: 



33. A method of scheduling events us in g- electronic * 
mail, comprising: 

preparing an electronic mail message contain- 
ing scheduling information and sending it to a 
predetermined event scheduling system ad- 
dress; 

receiving the electronic mail message and stor- 
ing the electronic mail message in a message 
database; 

accessing the message database and parsing 
the received electronic mail message to extract 
scheduling information therefrom, the schedul- 
ing information including event scheduler data, 
event data, resource data, and participant data; 
storing the extracted scheduling information in 
a predetermined format in a globally accessible 
record; 

processing the scheduling information in the 
globally accessible record and accessing 
schedule information stored in a schedule in- 
formation database, performing a function ac- 
cording to the data therein, and preparing and 
sending an outgoing electronic mail message 
to the sender and any affected event participant 
to acknowledge and report on the performed 
function. 

34. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
scheduling an event according to the extracted 
scheduling information; 
storing scheduling information associated with 
the scheduled event in an event record, send- 
er's schedule record, participant's schedule 
record, and a resource record in the schedule 
information database; and 
preparing and sending an outgoing electronic 
mail message to the sender and any affected 
event participant to acknowledge and report the 
scheduled event. 



storing electronic mail messages destined for 
the system sent by the sender in a message 
database; and 

scanning the message database for new mes- 
sages. 

31. The method, as set forth in claim 30, further com- 
prising checking for electronic viruses in the elec- 
tronic mail messages in the message database. 

32. The method, as set forth in claim 30, further com- 
prising verifying that the sender is an authorized us- 
er of the system. 



45 35. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
obtaining a time window stored in the sender's 
50 schedule record in response to the time window 

being absent from the globally accessible 
record; 

checking for scheduling conflicts within the time 
window by accessing participants' schedule 
55 records and resource records; 

scheduling an event by storing event data in the 
schedule information database; and 
preparing and sending an electronic mail mes- 
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sage to each event participant announcing the 
scheduled event. 

36. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
obtaining a time period stored in the sender's 
schedule record in response to the time window 
being absent from the globally accessible 
record; 

checkingforschedulingconflicts within the time 
period with the participants' schedule records 
and resource records; and 
preparing and sending an electronic mail to the 
sender reporting scheduling conflict data. 

37. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
scheduling an event by storing event data in the 
schedule information database regardless of 
participant schedule conflict; and 
preparing and sending an electronic mail mes- 
sage to each event participant announcing the 
scheduled event. 

38. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
deleting an event record in the schedule infor- 
mation database; 

removing the scheduled event from partici- 
pants' schedule records in the schedule infor- 
mation database; and 

preparing and sending an electronic mail mes- 
sage to each event participant announcing 
event cancellation. 

39. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 
locating, in the schedule information database, 
data associated with the scheduled event de- 
scribed therein; 

confirming the sender's participation in the 
scheduled event; and 

preparing and sending an electronic mail mes- 
sage to the sender acknowledging and report- 
ing the event confirmation. 

40. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

accessing the globally accessible record; 



locating, in the schedule information database, 
data associated with the scheduled event de- 
scribed therein; 

removing the sender as a participant in an 
5 event record associated with the event; 

removing the event from the sender's schedule 
record; and 

preparing and sending an electronic mail mes- 
sage to the sender acknowledging and report- 
10 ing the event withdrawal. 

41. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

15 accessing the globally accessible record; 

locating a schedule record of the sender, in the 
schedule information database, schedule data 
associated with the sender; and 
preparing and sending an electronic mail mes- 

20 sage to the sender containing the user's sched- 

uled events. 

42. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

25 

accessing the globally accessible record; 
locating a schedule record of the sender, in the 
schedule information database, containing 
preference data associated with the sender; 
30 updating the sender's preference data in the a 

user information record in the schedule infor- 
mation database; and 

preparing and sending an electronic mail mes- 
sage to the sender reporting on the success 
35 and failure of preference updates. 

43. The method, as set forth in claim 33, wherein 
processing the scheduling information comprises: 

^0 accessing the globally accessible record; 

locating a schedule record of the sender, in the 
schedule information database, containing 
preference data associated with the sender; 
and 

45 preparing and sending an electronic mail mes- 

sage to the sender containing help information 
in response to the data in the globally accessi- 
ble record and the preference data. 

so 44. The method, as set forth in claim 33, further com- 
prising checking for electronic viruses in the elec- 
tronic mail messages in the message database. 

45. The method, as set forth in claim 33, further com- 
55 prising verifying that the sender is an authorized us- 
er of the system. 
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EVENT COULD NOT BE 
LOCATED IN THE DATABASE 



~7~ 

302 



BUILD E-MAIL MESSAGE 
TO INFORM SENDER THAT 
HE IS NOT AUTHORIZED TO 
CANCEL THIS EVENT AND 
SEND VIA E-MAIL SYSTEM 

— 7~~ 



308 



314- 



316 



BUILD E-MAIL MESSAGE 
TO CANCEL THIS EVENT 
AND SEND TO EACH 
PARTICIPANT VIA 
E-MAIL SYSTEM 



DELETE EVENT RECORD 



304 



RETURN TO MAIN 
CONTROL PROGRAM 
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EVENT CONFIRMATION 
ROUTINE 




SEARCH SCHEDULE 
RECORD(S) OF AFFECTED 

RESOURCE FOR THIS 
EVENT BASED ON EVENT 

INFORMATION IN GAR 




BUILD E-MAIL MESSAGE 
TO INFORM SENDER 
THAT THE DESCRIBED 
EVENT COULD NOT BE 
LOCATED IN THE DATABASE 



330 
2- 



GET UNIQUE EVENT ID 
FROM RESOURCE'S 
SCHEDULE RECORD 
FOR THIS EVENT 



USE UNIQUE EVENT ID TO 
LOCATE THE EVENT RECORD 



-324 



YES 



IS USER'S 
EVENT CONFIRMATION FLAG 



SET TO UNCOMFIRMED 
STATE? 



NO 



336 



UPDATE USER'S SCHEDULE 
RECORD TO REFLECT THIS 
EVENT AND SET EVENT 
CONFIRMATION FLAG IN 
THIS EVENT RECORD 



-338 



FIG. 16 



RETURN TO MAIN 
CONTROL PROGRAM 



334 
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SEARCH SCHEDULE 
RECORD(S) OF AFFECTED 

RESOURCE FOR THIS 
EVENT BASED ON EVENT 

INFORMATION IN GAR 



-354 




GET UNIQUE 
EVENT ID 
FROM RESOURCE'S 
SCHEDULE RECORD 
FOR THIS EVENT 

~T~ 

358 



. 360 

i 

USE UNIQUE EVENT ID TO 
LOCATE THE EVENT RECORD 




370- 



372- 



USE THE EVENT RECORD 
TO LOCATE THE AFFECTED 

SCHEDULE RECORD OF 
THE SENDER 



UPDATE OR REMOVE 
SCHEDULE RECORD FOR 
SENDER ASSOCIATED 
WITH THIS EVENT 



BUILD E-MAIL MESSAGE 
TO INFORM SENDER 
THAT THE DESCRIBED 
EVENT COULD NOT BE 
LOCATED IN THE DATABASE 

— 7— 

362 



BUILD MESSAGE TO 
INFORM SENDER THAT HE 
IS NOT ASSOCIATED WITH 
THIS EVENT AND DATABASE 

WAS NOT UPDATED 

— T~~ 



368 



374- 



376- 



BUILD E-MAIl 
CONFIRM TH> 
SERVICE WA! 
SEND VIA E- 


. MESSAGE TO 
\T WITHDRAW 
5 DONE AND 
MAIL SYSTEM 


* 


REMOVE Rf 
TO SENDER 
EVENT f 


TERENCES 
FROM THIS 
iECORD 



FIG. 17 



364 



RETURN TO MAIN 
CONTROL PROGRAM 



) 
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FIG. 18 




408 



OBTAIN DEFAULT START 
TIME AND END TIME 
SCHEDULE REPORT 
PARAMETERS FROM 
USER RECORD 



LOCATE SCHEDULE RECORD 
OF FIRST EVENT FOR USER 
IN THIS TIME WINDOW 



BUILD E-MAIL MESSAGE 
TO INFORM SENDER 

THAT SCHEDULE REPORT 
FOR THIS USER 
IS NOT AUTHORIZED 



400 



C 



DOES 
RECORD PRIVACY 
SETTING DISALLOW REPORT 
INCLUSION TO 
SENDER? 

412 

YES 



NO 



ADD EVENT 



NFORMATION 



420 



SEND SCHEDULE 
REPORT TO SENDER 
VIA E-MAIL SYSTEM 




FOR THIS EVENT TO 
SCHEDULE REPORT 

: 1 — <T 

414 



RETURN TO MAIN 
CONTROL PROGRAM 



yM02 



LOCATE SCHEDULE RECORD 
OF NEXT EVENT FOR USER 



T 



■418 
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440 



REMOTE TOOL PREFERENCE 
SETTING ROUTINE 



442- 



444- 



452- 



456- 



458- 



READ FIRST PREFERENCE 
DIRECTIVE FROM THE CAR 



CHECK THE VALIDITY OF 
EACH PARAMETER FOR THIS 
PREFERENCE DIRECTIVE 




FIG. 19 



ADD PREFERENCE DIRECTIVE 
REJECT DESCRIPTION 
WITH DATA TO NEGATIVE 
FEEDBACK REPORT 



448 



ADD PREFERENCE UPDATE 
DESCRIPTION WITH DATA TO 
POSITIVE FEEDBACK REPORT 



I 



UPDATE PREFERENCE 
INDICATORS AND DEFAULT 
DATA IN USER'S RECORD 
AS DIRECTED 




FORMAT ANY POSITIVE 
AND NEGATIVE FEEDBACK 
REPORTS AS SPECIFIED 
BY UPDATED USER"S 
PREFERENCES 



SEND ANY POSITIVE 
AND NEGATIVE FEEDBACK 
REPORTS TO THE SENDER AS 
SPECIFIED BY UPDATED 
USER'S PREFERENCES 



460^ 



I 



RETURN TO MAIN 
CONTROL PROGRAM 
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EE 



E-MAIL SCHEDULE TOOL SERVICE LAUNCHER 



File Edit Navigate Help 



Clear FormTI 

Edit Preferences I Scheduler: | John Doe 



Submit 1 



J ^Exclude Scheduler From Event 



Location: [Conference Room 10~ 
Participants: 



William Wallace 
Dr. Richard Kimble 
Jack Ryan 
Mrs. Doubtfire 
Rob Roy 
James Bond 



Service Requested: I Event Conflict Detector T| (pj 
Response Option 1: | Pass-Schedule Even! f| p] 



Response Option 2: 1 Fail-Suoaest Alternative 



r Start — — 
Date: |Jon | 

Time:[or[ 


E/Q3/G5EI 


rEnd 

Dote: | Jon 

Time: foTl 


a/aa/Dnoia 



Event Title: j Protocol Enhancement Design Meeting 



Description: Agenda - blah - blah - blah 



FIG. 20 
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